1. Technical Field
The present invention relates to network file systems and, in particular, to supporting a uniform name space and transparent migration and replication of individual file systems. Still more particularly, the present invention provides a method, apparatus, and program for separate representations of file system locations from the data in referring file systems.
2. Description of Related Art
A network file system is a mechanism, an architecture, that allows a computer to use files on a separate machine as if they were local to the first machine. Network file systems include a high-level network protocol that provides the structure and language for file requests between clients and servers. The protocol provides the commands for opening, reading, writing and closing files across the network and may also provide access to directory services. In network file systems that support referrals, a client may ask a server for information about a name that appears in a first file system, as seen from the client, but is a reference to a second file system. As such, the response from the first file system must include information about the second file system, such as its location in the network. The client will then “mount” the second file system. Mounting simply means setting up the client's operating system to do input/output (I/O) operations on a file system.
FIGS. 1A-1C depict example network file systems.
Particularly, with reference to FIG. 1A, file system 106 includes a directory “usr.” The “usr” directory includes a reference to file system “foo.” The reference redirects a client to file system 116.
It is assumed that objects are arranged in a treelike structure, where files are arranged in directories and directories can contain other directories. Access to objects is achieved using path names, where a component of the path name designates the next sub-directory in the tree. The path starts at the top of the tree. A common convention uses forward slashes or back slashes to separate sub directories, and a single slash or backslash at the beginning of the path refers to the top of the hierarchy. For example, the path /a/b/C refers to an object “C” that is in directory “b.” Directory “b” is in directory “a,” which belongs at the top level of the hierarchy.
A file system may be moved from one location to another, such as to a new server. The referenced location must then redirect the client to the new location of the file system, and the source of the reference must be changed to indicate the new location of the file system as well. With reference to FIG. 1B, file system 106 includes a directory “usr.” The “usr” directory includes a reference to file system “foo.” The reference redirects a client to file system 116. However, “foo” has moved to file system 126. Therefore, file system 116 must include information to redirect the client to file system 126. At the same time, the information in file system 106 that had directed clients to file system 116 must be changed to direct them to file system 126.
A file system may also be replicated for increased reliability. Multiple file systems can thus reference a mounted file system. For example, in FIG. 1C, file system 106 includes a reference to file system “foo” in file system 116, file system 136 includes a reference to file system “foo” in file system 146, and file system 156 includes a reference to file system “foo” in file system 166. The file system “foo” moved to file system 126. Therefore, file systems 116, 146, 166 must be updated to include information to redirect the client to file system 126. However, too many updates results in inefficiency and a higher likelihood for error. For example, in FIG. 1C, file system 166 is not updated and the client is not redirected to the correct file system.
Similarly in FIG. 1C, the references to file system “foo” in file systems 106, 136, and 156 need to be updated so as to direct clients straight to file system 126 rather than any of 116, 146, or 166.
FIGS. 2A and 2B illustrate examples of file systems that allow mounting on remote machines. FIG. 2A depicts an example operation using Network File System (NFS), version 4 (NFSv4), which is an example of a network file system that allows mounting on remote machines. Client 208 requests an object “X” from file system (FS) server #1206 (step 1). However, X is a mounted file system existing on FS server #2216 and FS server #1206 sends a redirection message identifying FS server #2 and the path, “/a/b/c/X,” used to find X (step 2). Next, client 208 uses the information in the redirection message to access /a/b/c/X on server #2 (step 3).
NFSv4 requires that each referencing server include knowledge of the location and path for each mounted file system in the references returned to its clients. A server can send a redirection message that redirects the client to the server itself. This may be useful, for example, when a file system object is moved within a server. In addition, a chain of redirection messages may be used, for example, when an object is moved more than once. Thus, using NFSv4 or similar network file systems, particularly with multiple referencing servers, the likelihood for error exists.
As another example, FIG. 2B depicts an example operation of using the DCE's Distributed File System (DCE/DFS), which is another example of a network file system that allows referrals to remote machines. Using DCE/DFS, client 208 requests an object “X” from FS server #1206 (step 1). However, X is a mounted file system existing on FS server #2216 and FS server #1206 sends an indirection response including file system identifier “Y” used to find the file system (step 2). Next, client 208 requests the location of “Y” from file system (FS) location database 220 (step 3). The FS location database returns the location of Y, “FS server #2,” to client 208 (step 4). Thereafter, client 208 uses the location of FS server #2 to request the object from FS server #2216 (step 5).
NFSv4 and similar network file systems require that a referring server know the correct locations where to direct clients. The obvious implementation of referrals in NFSv4 and similar network file systems is to embed the locations of the referenced file systems directly in the data stored in the referencing file system. The combination of the movability of the referenced file systems and the replicability of the referencing file systems makes this a cumbersome solution: if a referencing file system is replicated to many read-only locations and a referenced file system is subsequently moved, all the instances of the referencing file systems must be updated even though they are read-only. DCE/DFS avoids this complication by storing only an identifier for the target file system in the referencing file system, so that the client looks up the current location for the file system given the file system identifier from the referencing server. It would be much less cumbersome for the client, not to mention conformant with NFSv4 and similar network file systems, if the server could handle the changing of file system locations without explicit updating of all references.